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Yhis  study  evaluated  four  networking  and  two  summarisation  schemes  for 
use  in  the  MX  management  information  system.  Results  of  the  evaluation  indi¬ 
cated  that  the  hierarchical  networking  system  and  the  activity  coding  summari¬ 
zation  technique  were  superior  for  meeting  user  requirements.  The  report 
describes  how  these  recommended  schemes  and  techniques  csn  be  implemented  into 
MX  and  provides  an  example  of  a  network  hierarchy.*: _ 
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FOREWORD 


This  investigation  was  performed  for  the  U.S.  Arjny  Corps  of  Engineers, 
Management  Support  Office,  Corps  of  Engineers  MX  Program  Agency  (CEMXPA), 
under  IAO  No.  E87-81-7151,  "Integrated  Hierarchical  Networks  for  MX";  Work 
Unit  439-QR1. 

The  work  was  performed  by  the  MX  Team,  Facility  Systems  Division  (FS), 
U.S.  Army  Construction  Engineering  Research  Laboratory  (CERL).  Mr.  Richard 
Fraser  was  the  CEMXPA  Project  Monitor.  Mr.  E.  A.  Lotz  is  Chief  of  CERL-FS. 

COL  Louis  J.  Circeo  is  Commander  and  Director  of  CERL,  and  Dr.  L.  R. 
Shaffer  is  Technical  Director. 
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MX  HIERARCHICAL 
NETWORKING  SYSTEM 


1  INTRODUCTION 


Background 

In  April  1980,  the  Corps  of  Engineers'  South  Pacific  Division  asked  the 
U.S.  Army  Construction  Engineering  Research  Laboratory  (CERL)  to  develop  a 
concept  and  implementation  plan  for  a  system  to  manage  '.he  design  and  con¬ 
struction  of  MX  Missile  System  facilities.^-  This  general  concept  study  noted 
the  need  for  a  detailed  evaluation  of  the  requirements  to  implement  the 
management  system.  One  area  recommended  for  further  study  which  is  discussed 
in  this  report  is  the  adaptation  of  commercial  software  to  provide  an 
integrated  scheduling  and  progress  reporting  system. 

To  speed  implementation  of  the  management  system,  a  prime  criterion  was 
to  make  extensive  use  of  "off-the-shelf,"  commercially  available  software  such 
as  Project/2  —  a  Critical  Path  Method  (CPM)  networking  and  resource  leveling 
system.  Where  commercially  available  software  could  not  completely  meet  user 
needs,  this  report  recommends  procedures  and  techniques  to  enhance  the  exist¬ 
ing  commercial  software. 


Objective 

The  objective  of  this  study  was  to  evaluate  various  networking  and  sum¬ 
marization  schemes  and  select  for  use  in  the  MX  system  those  which  would  pro¬ 
vide  the  greatest  benefits  to  the  user  and  be  most  compatible  with  system 
software . 


Approach 

User  needs  were  investigated  so  that  the  systems  could  be  evaluated  in 
terms  of  how  well  they  could  fulfill  these  requirements  (Chapter  2).  Four 
potential  networking  schemes  and  two  summarization  schemes  were  then  analyzed 
to  find  which  would  best  satisfy  the  needs  of  the  MX  system  (Chapters  3  and 
4).  Based  on  this  evaluation,  the  hierarchical  networking  scheme  and  the 
activity  coding  summarization  scheme  were  judged  to  be  superior  for  meeting 
user  requirements.  A  description  of  how  these  schemes  can  be  implemented  into 
MX  has  been  provided  (Chapter  5).  • 
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Lew  (Electronic  Data  Systems,  December  1980). 


This  investigation  is  limited  to  evaluating  the  flow  and  structure  of 
scheduling  and  progress  reporting  information  within  the  Construction  Deploy¬ 
ment  Management  Information  System  (MIS)  and  with  interface  points  of  other 
MISs  (e.g.,  Missile  System  MIS).  The  principal  users  of  the  Construction 
Deployment  MIS  are  the  Corps  of  Engineers  MX  Program  Agency  (CEMXPA),  Air 
Force  Regional  Civil  Engineering  (AFRCE) ,  the  Office  of  the  Chief  of 
Engineers,  and  Headquarters  Air  Force  -  Logistics  and  Engineering. 


Assumptions  and  Constraints 

This  report  was  based  on  the  following  assumptions  and  constraints  which 
represent  the  current  planning  philosophy  of  the  MX  Program: 

1.  The  MX  Management  Information  System  (MX-MIS)  will  support  the  Corps 
of  Engineers  and  Air  Force  engineering  and  construction  community.  An  exten¬ 
sive  communications  and  MIS  will  be  needed  by  this  widely  dispersed  group. 

2.  The  MX-MIS  will  automatically  interface  with  the  program  manager’s 
system  being  developed  by  the  Ballistic  Missile  Office  (BMO)  and  the  deploy¬ 
ment  systems  being  developed  by  the  Site  Activation  Task  Force  (SATAF),  both 
Air  Force  systems  (see  Figure  1). 

3.  The  MX-MIS  will  allow  more  effective  use  of  personnel  stationed  in 
the  field. 


A.  Maximum  use  will  be  made  of  standard  hardware  and  software  selected 
to  enable  expansion  and  insure  compatibility.  Project/2  has  been  selected  to 
provide  initial  CPM  capabilities  for  the  MX-MIS. 

5.  All  Corps  offices,  Corps  contractors,  and  Air  Force  contractors  will 
provide  network-based  (CPM)  schedule  data  in  accordance  with  a  pre- 
established,  contractually  approved  level  of  reporting. 
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Figure  1.  Management  information  interface. 


2  MANAGEMENT  CONCEPTS  AND  USER  REQUIREMENTS 


The  in-place  value,  speed  of  construction,  and  impact  on  limited 
resources  of  MX  construction  pose  management  problems  never  before  encountered 
in  civil  works  or  military  construction.  While  relatively  effective  for  nor¬ 
mal  construction  programs,  the  Corps  of  Engineers'  existing  management  systems 
cannot  be  expected  to  provide  a  coordinated  management  effort  for  a  program  as 
complex  as  MX . 

To  meet  this  need,  the  Management  Support  Office  of  the  Corps  of 
Engineers'  MX  Program  Agency  (CEMXPA)  was  tasked  with  providing  a  new  genera¬ 
tion  management  system  for  MX.  In  July  1980,  CEMXPA,  the  Construction 
Engineering  Research  Laboratory  (CERL),  and  Electronic  Data  Systems  (EDS)  —  a 
GSA  contractor  —  surveyed  users  and  evaluated  alternative  concepts.  Their 
report*  recommended  a  two-path  approach  to  implementation.  The  first  path, 
anticipated  to  take  about  3  years  to  implement,  recommended  a  long-range  sys¬ 
tem  capable  of  handling  peak  construction  loads.  However,  due  to  the  develop¬ 
ment  time  required,  this  approach  would  not  solve  the  problems  of  supporting 
the  critical  planning  phase  of  the  program;  therefore,  a  second-path,  interim 
approach  baited  on  identifying  and  selecting  commercial  and  government 
hardware/ software  was  chosen  that  could  provide  an  immediate  operational  capa¬ 
bility.  This  approach  quickly  provided  users  with  a  computer  (initially  Boe¬ 
ing  Computer  Services  and  later,  San  Antonio  Data  Center),  terminals,  and 
software  (Project/2,  a  network  analysis/resource  scheduling  system,  and  Focus, 
a  database  management  system). 

To  be  effective,  the  system  must  give  the  manager  an  information  network 
that  will  support  planning  decisions  and  provide  some  initial  construction 
monitoring  effort.  The  interim  system  provides  both  information  for  planners 
and  an  opportunity  to  field  test  integration  concepts  for  the  final  system  by 
validating  the  procedures  recommended  in  the  concept  study. 


Types  of  Information 

Management  needs  two  basic  types  of  information  to  make  decisions:  (1) 
text  in  the  form  of  directives,  memos,  and  reports,  and  (2)  network-related 
information  such  as  project  logic,  progress,  and  available  resources.  This 
report  deals  only  with  network-related  information  used  in  Project/2. 

Project  Logic 

Project  logic,  initially  developed  as  part  of  the  project  planning  pro¬ 
cess  and  later  modified  as  necessary,  is  a  list  of  (1)  all  activities  and 
milestones  needed  to  perform  the  work;  (2)  interdependencies  and  logical 
sequences  dictated  by  how  the  process  must  be  completed;  and  (3)  durations  of 
activities,  usually  in  the  form  of  workdays.  In  addition,  external  con¬ 
straints  are  required  when  the  network  has  availability  dates,  milestones,  or 
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need  dates  that  are  beyond  the  control  of  the  network  and  manager.  These  to  a 

particular  time,  once  the  basic  logic  has  determined  schedule  flexibility 
(available  float)  . 

l\0l\3S 

Progress  is  reported  as  the  work  is  executed.  Progress  requires  as  input 
a  reported  start  date  plus  at  least  one  of  the  following:  finish  date,  per¬ 
cent  complete,  days  complete,  days  remaining.  The  manager  can  use  this  infor¬ 
mation  to  compare  actual  progress  to  the  planned  schedule. 

Aval  Jab  .V  Resources 

Available  resources  can  be  money,  equipment,  materials,  or  manpower.  By 
comparing  available  resources  with  the  needs  of  the  preliminary  unconstrained 
schedule,  the  manager  can  get  a  more  realistic  schedule  for  doing  the  work. 

To  understand  how  the  user's  data  must  tie  together,  several  Project/2 
oriented  management  procedures  must  be  understood.  Carrying  out  a  construc¬ 
tion  program  is  an  iterative  process;  i.e.,  the  manager  must  constantly 
respond  to  new  and  increasingly  more  detailed  information.  The  process  can  be 
broken  down  into  three  phases:  (1)  planning,  (2)  execution,  and  (3)  perfor¬ 
mance  measurement. 

The  planning  phase  has  two  steps:  developing  network  logic,  and  then 
scheduling  various  tasks  within  that  logic.  When  planning  manually,  managers 
tend  to  combine  these  steps;  however,  to  successfully  use  a  C PM  system  such  as 
Project/2,  the  steps  must  be  split  so  that  only  technically  valid  precedence 
relationships  are  created.  Establishing  parallel  network  logic  rather  than 
unnecessary  sequential  logic  allows  the  computer  to  better  allocate  resources 
and  minimize  the  project  time  schedule. 

In  the  execution  phase,  the  user  manages  the  work  in  accordance  with  the 
schedule  developed. 

In  the  performance  measurement  step,  the  manager  reports  the  project's 
actual  progress,  which  is  then  compared  to  planned  progress.  The  system 
informs  the  user  of  schedule  slippages  delaying  the  project  and  slippages 
that,  if  allowed  to  continue,  will  delay  the  entire  program.  In  this  phase, 
the  CPM  system  provides  a  reporting  system  for  both  the  manager  and  higher- 
1 -ivel  supervisors.  It  also  summarizes  the  raw  data  into  a  meaningful  format 
and  provides  information  about  future  trends. 

If  actual  work  slips  significantly  from  the  manager's  schedule,  he*  must 
then  decide  how  to  reallocate  available  resources  within  the  approved  plan. 

If  this  does  not  maintain  the  schedule,  more  drastic  measures  are  needed.  He 
must  then  re-evaluate  the  original  logic  or  work  with  other  managers  to  allo¬ 
cate  more  resources  to  this  work.  The  final  option  is  to  develop  alternate 
logic  with  other  managers  to  allow  this  milestone  to  slip,  but  make  every 
effort  to  maintain  higher  level  milestones.  This  sequence  of  procedures  can 


*  The  male  pronoun  is  used  to  denote  both  genders. 
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prevent  unnecessary  modification  of  the  network  logic  or  schedule;  it  will 
also  prevent  over-optimization  of  an  individual's  sub-network  at  the  expense 
of  the  total  network. 


Organizational  Concept 

Conceptually,  the  Corps'  management  philosophy  will  continue  to  allow 
decentralized  management  responsibility  within  the  limitations  imposed  by  the 
need  for  close  coordination  on  the  MX  project.  The  project  will  be  admin¬ 
istered  by  CEMXPA  at  Norton  AFB,  CA  (Figure  2).  Engineering  functions  will  be 
tasked  to  existing  design  districts,  with  construction  supported  by  the  Corps 
of  Engineers’  MX  Construction  Office  (CEMXCO)  (Figure  3);  new  Corps  area 
offices  will  be  created  as  the  project  progresses. 


Figure  2.  M-X  proposed  program  agency  organization  chart. 
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Figure  3.  M-X  construction  office  proposed  organization  chart, 
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The  Air  Force  Regional  Civil  Engineers  (AFRCE)  will  act  as  liaison 
between  the  Corps  and  the  Air  Force  for  the  MX  project.  The  management  system 
will  collect  and  summarize  data  for  the  Air  Force,  thus  treeing  AFRCE  staff 
for  coordination  work.  The  MIS  must  provide  the  AFRCE  with  access  to  summar¬ 
ized  progress  data  and  give  them  the  capability  to  respond  to  congressional  or 
other  inquiries  with  a  minimum  of  "paper  shuffling." 


Responsibility  for  Information  Quality 

Information  reporting  systems  have  often  failed  to  provide  high-level 
managers  with  either  timely  or  accurate  information.  In  fact,  the  very  nature 
of  a  "reporting"  system  can  cause  most  of  the  problem.  The  system  design 
often  reflects  only  higher-level  management  needs.  The  needs  of  the  person 
who  operates  the  system  —  usually  the  lowest-level  manager  or  his  clerical 
staff  —  are  not  given  adequate  consideration.  However,  if  the  information  in 
the  system  is  designed  to  help  the  lowest-level  manager,  the  data  would  be 
inherently  more  accurate  and  maintained  on  a  more  regular  basis,  not  just  at 
mandatory  reporting  time. 

If  the  MIS  provides  the  lowest-level  manager  information  needed  to  suc¬ 
cessfully  do  this  work,  the  information  needed  by  high-level  managers  can 
easily  be  collected  using  automated  techniques.  The  data  need  only  be  summar¬ 
ized  into  meaningful  high-level  management  information  to  be  useful. 


Timeliness  of  Information 


During  peak  loads  on  the  MIS,  most  information  will  be  related  to  con¬ 
struction  contractors'  networks  rather  than  to  design  or  general  planning. 

Upon  notice  to  proceed,  the  contractor  will  provide  the  resident  engineer  with 
a  network  showing  how  he  proceeds  with  construction.  The  resident  engineer 
will  then  review  the  logic  and  verify  contractual  compliance  dates.  If  the 
network  submittal  meets  the  contract's  requirements,  the  resident  engineer 
will  approve  the  network  and  make  it  available  on  the  system.  If  the  network 
is  not  approved,  the  contractor  must  modify  and  resubmit. 

An  approved  network  is  the  facility's  official  construction  plan.  Pro¬ 
gress  will  be  reported  and  contract  modifications  evaluated  against  the 
approved  network;  interim  payments  will  be  calculated  automatically  based  on 
the  reported  progress  and  value  associated  with  network  activities.  Thus,  the 
network  must  continue  to  reflect  the  project's  logic  and  progress.  It  is 
assumed  that  each  contractor  will  be  paid  twice  a  month  to  reduce  the  effectB 
of  the  present  cost  of  money,  and  payments  to  contractors  will  be  made  on  a 
staggered  basis.  The  currency  of  the  progress  information  in  the  system  will 
vary  from  1  day  to  2  weeks,  depending  on  the  specific  contract,  and  assuming 
progress  will  be  reported  only  for  payment  requests. 

Information  must  be  more  current  when  projects  require  close  coordination 
among  various  MX  participants.  Each  significant  milestone  which  directly 
affects  others  must  be  validated  more  often  as  its  completion  dates  approach. 
This  should  apply  to  only  a  few  activities  and  can  be  handled  as  the  need 
arises. 
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Access  to  Information 


The  system  has  three  general  types  of  users:  (1)  those  who  generate  and 
maintain  information,  (2)  those  who  read  and  approve  information  and,  (3) 
those  who  only  read  the  information.  Some  may  feel  that  there  should  be  a 
fourth  user  —  one  who  reads  and  modifies  information  input  by  others;  how¬ 
ever,  the  potential  for  creating  invalid  data  is  extremely  high  if  this  is 
allowed.  If  information  input  by  others  must  be  altered,  the  originator  of 
the  information  should  make  the  changes.  Otherwise,  second-guessing  apparent 
"errors"  can  have  disastrous  effects  on  the  database's  quality.  If  the  origi¬ 
nator  makes  the  changes,  all  participants  will  become  aware  of  and  can  verify 
the  need  for  these  changes. 

It  is  anticipated  that  information  will  flow  through  the  system  in 
several  steps.  The  user  responsible  for  generating  the  data  inputs  and  edits 
the  information.  It  is  recommended  that  this  be  done  on  a  private  "scratch" 
file  to  prevent  accidental  destruction  of  the  public  database  and  to  keep 
other  users  from  reading  files  that  are  not  yet  valid.  After  a  file  is  pro¬ 
duced  (e.g.,  approved  construction  network  submittal),  it  is  still  recommended 
that  the  actual  data,  such  as  network  progress,  be  reported  to  the  private 
file  to  identify  errors  before  the  data  is  "released”  to  the  public  file. 

Once  the  data  is  acceptable,  it  can  overlaid  on  the  previous  data  without 
danger  of  users  getting  incomplete  or  improper  inform ition. 


Security  Requirements 

By  Its  very  nature,  an  MIS  brings  together  data  from  many  sources,  syn¬ 
thesizes  them  into  useful  information,  and  distributes  it  to  various  managers. 
The  need  to  combine  the  information,  and  to  make  it  available  to  anyone  who 
needs  it,  creates  many  security  problems.  Potential  controls  include: 
account  passwords,  program  passwords,  data  files  passwords,  menu  lockout,  and 
independent  databases. 


Account  passwords  prevent  unauthorized  persons  from  using  an  individual 
computer  account. 

Program  passwords  allow  only  authorized  users  to  access  a  particular  pro¬ 
gram  or  group  of  related  programs.  They  prevent  unauthorized  users  from  mani¬ 
pulating  data  (e.g.,  modifying  pay  requests). 

Data  files  passwords  are  usually  of  two  types:  Read/write  access  or  Read 
Only  access.  Read/write  allows  a  user  to  create  or  modify  a  file  while  others 
may  be  allowed  only  to  read  that  file. 

Menu  lockout  can  prevent  an  unauthorized  user  from  using  certain  com¬ 
mands,  or  accessing  data  files  or  submodules  of  a  system.  The  main  advantage 
of  this  control  is  to  prevent  accidental  alteration  or  destruction  of  files  by 
someone  unfamiliar  with  the  system. 

Independent  databases  is  a  simple  concept  for  providing  security.  If  the 
data  remains  as  one  file,  only  the  weakest  security  measures  can  be  used  for 
protection  (e.g.,  menu  protection,  i .d .  protection).  However,  by  separating 


data  into  multiple  files,  stronger  security  measures  can  be  used  to  enhance 
security. 


Anticipated  Volumes 

Existing  networks  were  analyzed  to  estimate  the  size  of  the  network(s) 
needed  to  support  anticipated  MX  deployment,  particularly  for  the  construction 
phase.  The  MX  program  was  analyzed  at  three  levels  of  detail  and  the  informa¬ 
tion  summarized  to  determine  the  number  of  activities  needed. 

At  the  highest  level  of  summary  (level  1),  the  quantities  reflect  a  pro¬ 
gram  manager's  information  needs.  The  second  level  (level  2)  reflects  the 
information  needed  to  analyze  the  deployment  masterplan.  This  is  the  facili¬ 
ties  level  of  detail.  The  third  level  (level  3)  reflects  the  quantities  of 
activities  expected  at  the  "contract”  level  of  detail,  i.e.,  the  construction 
activities  required  for  a  facility  or  contract. 

Figure  A  lists  the  total  activities  expected  at  each  major  division  of 
work  and  the  relative  level  of  summary.  Figure  5  shows  the  number  of  networks 
envisioned  and  the  probable  number  of  activities  needed  to  represent  the  MX 
program,  summarized  by  responsible  office. 


No.  of 
Networks 


No.  of 
Activities 


Level  1  (Program  Summary)  100 

Level  1  SUBTOTAL  1  100 

Level  2  (Deployment  Masterplan) 

DAA  350 

0BTS  200 

0PBASE  600 

DDA/DTN  1,200 

AUX  0PBASE  550 

LIFE  SUPPORT  300 

CONSTRUCTION  SUPPORT  300 

TEST  FACILITIES  (VANDENBERG)  60 

EIS/BCP  150 

REAL  ESTATE  200 

MISC.  2°0 

Level  2  SUBTOTAL  11  4110 

Level  3  (Contractors  Networks) 

DAA  (2  NETS)  6,000 

OBTS  (4  NETS)  4,000 

OPBASE  (90  NETS)  45,000 

DDA/DTN  (45  NETS)  80,000 

AUX  OPBASE  (80  NETS)  40,000 

LIFE  SUPPORT  (9  NETS)  1,650 

CONSTRUCTION  SUPPORT  (18  NETS)  4,000 

TEST  FACILITIES  (11  NETS)  5,500 

REAL  ESTATE  (18  NETS)  10,000 

MISC.  (3  NETS)  500 

Level  3  SUBTOTAL  280  196,650 

TOTAL  292  200,860 


Figure  4.  Anticipated  network  volumes. 
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Office 


Number  of 
Networks 


Number  of 

Actlvl ties /Mile stones 


CEMXPA 

Unsupported 

Supported 

Unsupported 

Supported 

Program  Summary 

— 

1 

100 

Deployment  Masterplan 

CEMXCO 

2 

260 

Deployment  Masterplan 

AFRCE 

0 

3 

900 

Deployment  Masterplan 

SPD-RE 

1 

0 

150 

— 

Deployment  Masterplan 

SPK-RE 

0 

1 

— 

200 

Aquisition  Network 

SPL-We8tern  Area  Office 

11 

0 

10,000 

Contractor  Networks 

Logistics 

11 

0 

5500 

Construction  Support 

Construction  Support 

9 

0 

2000 

Construction  Support 

9 

— 

2000 

— 

*  Supported  Indicates  a  lower  level  network  feeds  data  to  the  network  listed. 


Total 

360 

900 

150 

200 

10.00C 

5500 

2000 

2000 


Figure  5.  Network  maintenance  by  responsible  office. 


Number  of 

Number  of 

Office 

Networks 

Activities/Milestones 

Unsupported 

Supported 

Unsupported 

Supported 

Total 

Design  —  SACR/LA/OMAHA 

Deployment  Masterplan 

5 

— 

1,755 

— 

1,755 

Area  Office  1 

O 

570 

Deployment  Masterplan 

'■  “ 

J 

Life  Support  Network 

1 

1  JV 

SS  000 

55,720 

Contractor  Networks 

96 

Area  Office  4 

275 

Deployment  Masterplan 

1 

1  so 

Life  Support  Network 

1 

40 ,000 

__ 

40,425 

Contractor  Networks 

80 

Other  Area  Offices  (9) 

Life  Support  Network 

9 

— 

1,350 

80  000 

— 

81,350 

Contractor  Networks 

45 

Others 

POGS/Misc. 

_2 

. 

500 

— 

500 

281 

a 

198,555 

2,305 

200,860 

Figure  5.  (Cont'd) 
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3  POTENTIAL  NETWORKING  SCHEMES 


The  application  of  network-based  planning,  scheduling,  and  reporting  sys¬ 
tems  is  not  new.  However,  several  alternative  network-based  schemes  must  be 
evaluated  to  determine  the  best  solution  for  the  MX  project  because  of  its 
size,  duration,  cost,  and  complexity. 

To  help  determine  which  networking  scheme  best  meets  the  MX  program's 
needs,  a  criteria  checklist  was  developed  to  weigh  the  relative  merits  of  each 
scheme.  The  criteria  reflect  MX  programs  and  user  requirements  identified  in 
the  MX  Engineering  and  Construction  Management  and  Information  Systems  Concept 
Report.  Generally,  the  criteria  addressed  the  mechanics  of  how  information  is 
loaded  in  the  system,  translated  into  useful  information,  and  distributed 
through  the  management  organization. 

The  criteria  considered  in  this  report  are  defined  as  follows: 

1.  Single  Network  Limitation.  Will  the  scheme  allow  the  maximum  size 
network  anticipated  to  be  processed  in  a  single  computer  run? 

2.  Multiple  User.  Can  multiple  users  work  with  their  portion  of  the 
network  simultaneously  or  are  "bottlenecks”  likely? 

3.  Data  Security.  Can  a  user's  data  be  protected  from  alteration  or 
destruction  by  other  users? 

4.  Data  Access.  Can  a  user  easily  access  necessary  information? 

5.  Vertical  Information  Flow.  Does  information  easily  flow  vertically 
through  the  organization  with  a  minimum  of  manual  effort? 

6.  Horizontal  Information  Flow.  Are  all  interfaces  between  users  at 
any  level  integrated  to  provide  a  coordination  effort? 

7 .  Currency  of  Information.  Can  users  be  updated  quickly  about  changes 
that  may  Impact  their  work? 

8.  Turnaround.  How  quickly  can  the  results  of  a  computer  be  made 
available  to  the  user? 

9.  Ease  of  Implementation.  Given  the  existing  equipment  and  software, 
how  easily  (quickly)  can  a  scheme  be  implemented? 

10.  Processing  Costs.  What  is  the  relative  computer  cost  to  provide 
management  information  if  a  scheme  is  implemented? 

11.  Overall  Cost.  What  is  the  relative  operating  cost  (labor,  materials 
and  computer)  to  provide  management  information  if  a  scheme  is  implemented? 
(This  does  not  include  relative  cost  of  implementation.) 


V 
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Single-Network  Scheme 

The  single-network  scheme  Includes  all  activities  In  a  single  network 
(Figure  6a).  It  considers  all  of  the  relationships  between  the  diverse 
activities  needed  to  coordinate  the  project  properly.  Although  this  scheme 
most  directly  integrates  the  work  of  each  manager,  there  are  a  number  of 
shortcomings . 

Information  for  the  entire  project  is  limited  to  the  maximum  number  of 
activities  allowed  by  the  system  (usually  32,000).  Processing  time  and  costs 
are  also  high  because  a  large  amount  of  data  must  be  processed  after  every 
database  change.  Only  one  user  has  access  to  the  data,  thus  creating  an 
information  bottlneck;  thus,  if  multiple  users  are  allowed  access,  data 


Figure  6.  Potential  networking  schemes. 
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security  Is  compromised.  Finally,  to  obtain  specific  data,  the  user  must  use 
multiple  selections  in  order  to  define  a  narrower  group. 


The  size  limitations  could  be  overcome  by  varying  the  network's  preci¬ 
sion;  i.e.,  near-term  activities  could  be  more  precisely  defined  than  future 
activities  and  old  activities  dropped  as  they  are  completed.  This  method, 
which  is  a  sensible  basic  planning  technique,  could  also  be  applied  to  any  of 
the  four  schemes  discussed  in  this  chapter.  Future  activities  can  rarely  be 
defined  as  well  as  near-term  activities,  and  this  additional  detail  does  not 
necessarily  enhance  accuracy.  In  fact,  it  may  add  significantly  to  the 
planners'  workload  and  give  a  false  sense  of  detailed  knowledge  of  future 
activities. 


Multiple  Independent  Networks  » 

This  scheme  consists  of  using  two  or  more  independent  networks  to  include 
all  network-related  information  for  the  MX  project  (Figure  6b) .  This  scheme 
increases  the  total  number  of  activities  available  to  be  the  product  of  the 
maximum  number  of  activities  allowed  (by  the  system)  in  a  network  times  the 
number  of  Independent  networks.  Assuming  a  comparable  total  number  of  activi¬ 
ties,  the  processing  time  and  cost  for  this  scheme  should  be  less  than  that 
expected  for  a  single  network  since  fewer  activities  are  involved  in  each  net¬ 
work  calculation.  In  addition,  more  than  one  user  can  have  access  to  the  sys¬ 
tem  at  the  same  time.  The  number  of  users  can  equal  the  number  of  independent 
networks  if  necessary. 

However,  this  approach  requires  both  extensive  manual  communication  of 
interactions  between  the  independent  networks  and  manual  combining  of  informa¬ 
tion  for  reports.  This  manual  intervention  would  be  awkward,  time-consuming, 
and  could  introduce  errors. 


Multlprojecting 

Multiprojecting,  which  allows  multiple  independent  networks  to  be  pro¬ 
cessed  as  a  single  network,  automatically  coordinates  a  project,  thus  elim¬ 
inating  the  need  for  manual  communicating,  combining,  and  coordinating  (Figure 
6c).  Through  common  milestones,  the  automated  system  can  temporarily  combine 
individual  networks  into  a  single  network  having  the  significant  attributes  of 
each  “member"  network. 

The  advantage  of  multiprojecting  is  that  many  of  the  problems  encountered 
with  processing  a  single  large  network  are  eliminated,  yet  most  of  the  attri¬ 
butes  of  the  independent  network  scheme  are  retained.  Retaining  individual 
member  networks  reduces  processing  costs  and  spreads  the  responsibility  for 
maintenance  of  each  portion  of  the  network  among  the  various  managers.  Mul¬ 
tiprojecting  automatically  coordinates  each  member  network,  thus  reducing  the 
manual  effort.  Under  normal  conditions,  the  multiprojecting  scheme  is  con¬ 
strained  to  the  network  size  limitations  of  a  single  network  scheme. 
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Hierarchical  Networks 


The  previous  networking  schemes  have  not  addressed  the  problem  of  verti¬ 
cal  communication  within  the  MX  organization.  The  information  flow  can  be  in 
the  form  of  directives  or  management  summaries  that  are  sent  downward  to  the 
field,  or  progress  and  project  changes  that  are  summarized  upward. 

The  hierarchical  network  scheme  provides  not  only  the  horizontal  communi¬ 
cations  of  the  multiproject  scheme  but  also  the  vertical  communications  needed 
when  work  is  split  among  several  field  managers  (Figure  6d).  Although  all  of 
the  schemes  investigated  allow  the  summary  techniques  common  to  most  CPM  pro¬ 
cessors,  they  can  be  awkward  and  expensive  when  very  detailed  information  is 
summarized  repeatedly  to  a  higher  level.  Maintaining  summarized  information 
from  a  detailed  network  level  in  a  summary  data  file  with  multiple  read  access 
produces  two  improvements: 

1.  The  network  is  only  summarized  once  to  reduce  future  data  manipula¬ 
tion  for  reports. 

2.  The  summarized  data  can  be  made  available  without  the  raw  data,  thus 
reducing  the  opportunity  for  higher-level  management  to  "micro-manage." 


Information  Processing 

The  flexibility  and  access  to  information  of  all  the  schemes  could  be 
Improved  if  the  data  were  processed  through  a  scheduling  module  (Project/2) 
and  then  submitted  to  a  Data  Base  Management  System  (DBMS).  The  use  of  a  DBMS 
could  provide  several  advantages  over  the  scheduling  system  alone: 

1.  Consistency  in  data  across  networks  would  be  improved. 

2.  Both  ad  hoc  queries  and  standard  reports  would  be  available. 

3.  Requests  for  similar  data  across  networks  would  allow  automatic  col¬ 
lection  and  report  generation. 

4.  Non-standard  questions  from  parties  outside  the  Corps/AF  organization 
could  be  answered  quickly  and  easily. 


Evaluation  of  Networking  Schemes 

To  help  evaluate  the  schemes,  the  Networking  Schemes  Evaluation  Matrix 
was  developed  to  weigh  the  relative  merits  of  each  scheme  against  each  user 
requirement  'Figure  7).  Each  scheme  was  evaluated  and  rated  subjectively, 
based  on  the  authors'  judgment,  for  how  well  it  met  the  requirements.  If  a 
scheme  was  totally  unacceptable,  it  was  scored  with  a  zero  and  not  considered. 
Even  if  the  scheme  had  a  high  overall  rating,  it  was  not  considered  if  minor 
modifications  to  the  basic  concept  did  not  improve  its  unacceptable  ratings. 

The  matrix  Indicates  that  the  Hierarchical  Scheme  meets  user  requirements 
much  better  than  the  others.  Its  only  low  rating  was  for  the  relatively  high 
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Scale 


4  Best  Scheme 

3  2nd  Best  Scheme 

2  3rd  Best  Scheme 

1  Worst  Scheme 

Single 

Multiple 

Independent 

Multiproject 

Hierarchical 

0  Unacceptable 

Network 

Network 

Ne  twork 

Network 

Size  Limitations 

0 

4 

3 

4 

Multiple  User  Data  Entry 

0 

4 

4 

4 

Data  Security 

1 

4 

4 

4 

Data  Access 

0 

2 

3 

4 

Vertical  Info.  Flow 

2 

1 

2 

4 

Horizontal  Info.  Flow 

4 

0 

4 

4 

Currency  of  Info . 

4 

1 

2 

4 

"Turn  Around" 

0 

3 

3 

4 

Ease  of  Implementation 

4 

4 

4 

3 

Processing  Costs 

2 

4 

3 

1 

Overall  Costs 

2 

1 

3 

4 

T9* 

19* 

TT 

*Not  considered  due  to  unacceptable  Individual  ratings. 


Figure  7.  Networking  Schemes  Evaluation  Matrix. 


computer  processing  costs,  and  those  were  more  than  offset  by  the  reduction  in 
manual  labor  and  improved  data  handling. 

Use  of  the  most  automated  version  of  the  hierarchical  scheme  for  the  MX 
project  will  require  expenditures  for  significant  changes  to  the  scheduling 
system  (Project/2);  integration  of  a  Data  Base  Management  System  (Focus);  and 
development  of  a  menu  to  help  users  operate  the  programs  quickly  and  effi¬ 
ciently.  Additionally,  the  merits  of  maintaining  an  accurate  database  must  be 
weighed  against  these  anticipated  development  and  higher  operating  costs. 

Since  this  system  is  designed  as  a  management  information  system,  not  an 
accounting  system,  the  user  may  find  that  the  additional  information  and  accu¬ 
racy  that  a  DBMS  may  provide  is  really  unnecessary  for  most  management  deci¬ 
sions. 
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4  SUMMARIZATION  SCHEMES 


Two  summarization  schemes  were  Investigated:  one  groups  like  activities, 
and  the  other  generates  new  (pseudo)  activities  representing  all  activities 
between  pre-defined  milestones  in  a  lower  level  network.  In  both  schemes,  an 
activity  in  the  higher  level  (more  summarized)  network  may  represent  one  or 
more  activities  in  the  lower  level  network.  The  logic  representing  the  pre¬ 
cedence  relations  at  the  higher  level  (macro  logic)  may  not  fully  represent 
those  at  the  lower  level  (micro  logic).  The  degree  to  which  the  micro  logic 
is  represented  in  the  higher  level  network  varies  with  the  summary  techniques 
used . 


Activity  Coding 

Activity  coding  combines  lower-level  activities  with  similar  characteris¬ 
tics  into  a  single  activity.  Although  most  activities  will  be  summarized, 
some  activities  and  most  milestones  will  have  a  one-to-one  relationship  in 
each  network  level. 

Preassigned  activity  coding  is  based  on  the  existing  data  summarization 
capabilities  of  Project/2.  Besides  being  an  effective  selection/sort  mechan¬ 
ism,  this  scheme  is  available  on  the  existing  system;  very  little  additional 
data  would  be  required  to  implement  the  scheme  fully  in  a  hierarchical  system. 
In  addition,  activity  codes  and  descriptors  could  be  used  to  generate  new  sum¬ 
marized  activities  and  to  report  progress  upward  without  manual  intervention. 

The  major  drawback  of  this  scheme  is  that  activity  codes  can  disregard 
logic  at  the  lower  levels  and  can  cause  discontinuous  progress  to  be  reported 
—  a  situation  which  may  or  may  not  really  exist.  This  situation  becomes  less 
of  a  problem  as  the  level  of  summarization  becomes  higher.  Another  possible 
problem  is  automatic  generation  of  summarized  network  data  in  an  activity-on- 
arrow  (A/A)  format.  In  an  activity-on-node  (A/N)  format,  the  node  number 
could  be  generated  using  the  activity  code  numbers.  This  technique  could  also 
be  used  to  create  the  "I”  node  in  A/A  networks;  however,  creating  a  "J"  node 
number  that  consistently  reflects  the  precedence  relationships  in  the  summary 
networks  could  be  very  hard. 

One  solution  is  to  convert  all  summary  networks  to  A/N  format.  Since 
Project/2  can  programmatically  convert  the  data  from  A/A  to  A/N,  the  contrac¬ 
tors  could  submit  their  networks  in  either  format,  and  the  summarized  data 
would  always  be  converted  to  an  A/N  format. 


Pseudo  Activities 


The  pseudo  activity  scheme  uses  matching  milestones  at  various  levels  in 
the  hierarchy.  Two  types  of  information  are  created  to  provide  upward  report¬ 
ing  of  logic  and  progress  automatically.  A  new  (pseudo)  activity  created 
between  the  milestones  replaces  multiple  network  paths  created  at  the  detailed 
level.  Then  a  new  duration  is  created  for  the  pseudo  activity  by  calculating 
the  critical  path  between  the  milestones. 
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The  greatest  advantage  to  this  technique  is  changes  to  a  lower-level  net¬ 
work  are  automatically  incorporated  in  the  higher-level  network.  Unfor¬ 
tunately,  other  data  tied  to  the  higher-level  network  must  be  reported  manu¬ 
ally  (description  of  activities,  codes  for  manipulating  data),  and  processing 
costs  will  probably  be  higher.  In  addition,  only  the  USAF  PERT-COST  schedul¬ 
ing  system  can  process  the  data  in  this  way.  It  would  be  impractical  to 
modify  a  commercially  available  system  such  as  Project/2  for  this  type  of  sum¬ 
marization. 


Summarization  Evaluation 


The  existing  activity  coding  scheme  of  Project/2  appears  superior  to  the 
pseudo  activity  scheme  for  the  MX  program.  Potential  problems  with  loss  of 
detailed  logic  can  be  overcome  by  carrying  integrated  or  critical  logic  upward 
without  summarization  and  insuring  that  related  strings  of  activities  are  sum¬ 
marized.  In  addition,  the  relative  detail  from  one  network  level  to  the  next 
is  generally  such  that  loss  of  micro  logic  is  insignificant. 


25 


5  HIERARCHICAL  NETWORKING  PROCEDURES 


This  chapter  describes  how  the  hierarchical  networking  scheme  can  be 
implemented  into  the  MX  project. 

When  planning  a  large  construction  project,  a  "top  down"  approach  is  used 
to  develop  the  CPM  network.  First,  the  major  elements  are  identified  to 
determine  the  scope  of  the  work;  those  elements  become  better  defined  as  more 
specific  information  is  obtained.  In  the  context  of  MX,  preliminary  planning 
has  been  done  by  personnel  from  several  Districts  and  Divisions  to  create  a 
feasible  plan  based  on  their  collective  knowledge.  As  additional  information 
about  materials  and  the  construction  process  to  be  used  becomes  available,  the 
additional  detail  will  replace  the  more  general  data  or  omissions  in  the  pre¬ 
vious  single  network. 

The  large  single  network  can  then  be  replaced  by  multiple  networks  (pro¬ 
grammatically)  grouped  by  each  major  element  or  responsibility.  To  integrate 
the  "member"  networks,  common  milestones  are  identified  where  there  is  an 
interrelationship  among  activities  (Figure  8).  The  common  milestones  are 
given  identical  numbers,  descriptions,  and  codes;  this  provides  the  connecting 
point  between  the  two  (or  more)  networks.  When  the  member  networks  are  com¬ 
bined  through  multiprojecting  into  a  single  network  (Figure  9a),  each  redun¬ 
dant  set  of  milestones  is  replaced  with  a  unique  milestone  that  ties  the  net¬ 
works  together.  The  multiprojected  network  is  then  recalculated  (reflowed)  to 
provide  durations  and  dates  based  on  the  additional  interrelationships  (Figure 
9b)  . 


At  this  point,  the  master  network  represents  the  interaction  of  all 
members.  Each  planner  can  then  place  his  member  network  in  the  same  relative 
timeframe  as  the  master  network  by  placing  artificial  constraints  on  each 
milestone  that  interfaces  with  another  member  network  (Figure  9c).  The 
planner  can  do  this  automatically  by  selecting  the  applicable  interfaced  mile¬ 
stones  and,  with  minor  programming,  convert  these  milestones  into  the  form  of 
active  an  input  file  of  constraints.  Inserting  these  constraints  in  each 
member  network  would  relocate  each  network  into  its  proper  timeframe,  thus 
allowing  the  planner  to  continue  working  on  the  original  member  network  in  the 
proper  timeframe  without  modifying  the  master  network. 

If  an  artificial  constraint  (such  as  an  external  need  date)  creates  nega¬ 
tive  float,  the  planner  should  first  try  to  resolve  the  time  problem  within 
the  member  network.  After  attempting  to  solve  the  problem  internally  and 
probably  having  the  master  network  reflowed  to  take  advantage  of  any  other 
time  reductions,  the  network  would  either  become  feasible,  require  major 
changes  at  a  higher  conceptual  level,  require  slippage  in  need  dates,  or  more 
likely,  some  combination  of  these. 

If  using  this  iterative  process  makes  the  master  network  feasible,  the 
plan  could  begin  to  be  executed  as  planned.  Progress  would  initially  be 
reported  by  the  design  Districts,  real  estate  Districts,  and  environmental 
staff,  and  later,  as  construction  contracts  are  awarded  by  CEMXCO.  The  ini¬ 
tial  progress  would  be  loaded  manually,  using  normal  Project/2  procedures; 
however,  as  the  volume  increased,  it  would  be  loaded  automatically  through 
lower-level,  detailed  contractor's  networks. 
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BEFORE  MULTI  PROJECTING 


NET  "A" -REAL  ESTATE  (RE) 

dummy 

NET  “B"- DESIGNATED  TRANSPORTATION  NET  (DTN! 


AFTER  MULTIPROJECTING 


Figure  8.  Milestone  interface  between  fragment  networks. 
(Activity-on-Arrow  Notation) 


As  construction  contracts  are  implemented,  contractor  network  submittals 
will  be  given,  in  a  machine-readable  form,  to  resident  engineers  for  review 
and  approval.  If  the  submittal  is  feasible  and  meets  the  contract  require¬ 
ments,  including  system  compatibility,  the  network  becomes  the  official  con¬ 
tract  network;  hereafter,  progress  data  and  contract  modifications  are 

reported  to  the  network. 

Changes  to  the  contract  update  section  of  the  network  logic  should  rarely 
require  manual  intervention  at  the  member  network  level.  Assuming  that  the 
contract  network  will  be  represented  by  only  a  few  activities  at  this  level, 
contract  changes  should  only  affect  durations,  not  logic.  Most  major  logic 
will  be  developed  early  in  the  planning  process,  not  after  fixed  price  (rela¬ 
tively  well  defined)  contracts  have  been  executed.  The  one  exception  would  be 


MASTER 

NETWORK 

MANAGER 


USER  I 


Figure  9.  Integrated  hierarchical  networking  using  Project/2. 


in  networks  where  there  are  multiple  detailed  interrelationships  between  con¬ 
tracts,  specifically  government-furnished  products.  Because  of  the  limited 
amounts  of  some  products  or  services  available,  the  network  logic  may  undergo 
numerous  changes  if  the  Project/2  resource  allocation  processor  cannot  meet 
contractual  need  dates . 

Once  contract  progress  has  been  reported  to  the  official  file,  and  sum¬ 
marized  progress  has  been  reported  to  the  member  network  and  integrated  by 
multiprojecting  if  necessary,  managers  at  every  organizational  level  will  be 
able  to  get  summarized  reports  tailored  to  the  level  of  detail  appropriate  for 
their  work.  Three  basic  network  levels  are  anticipated:  (1)  a  program  summary 
network,  (2)  a  summary  (member)  network,  and  (3)  a  contract  network  with  sum¬ 
marization  capability  through  the  use  of  activity  coding  to  tailor  a  report  to 
any  intermediate  level. 

This  example  breakdown  of  the  network  hierarchy  (Figure  10)  is  based  on 
the  proposed  Project  Management  Plan,  dated  July  1981.  The  contract  level 
networks  represent  the  probable  quantities  of  networks  (and  activities)  that 
can  presently  be  expected  during  the  MX  construction  program.  The  networks 
have  been  grouped  and  assigned  to  each  area  office  based  on  the  management 
plan. 
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PROPOSED  NETWORK  HIERARCHY 

(BASED  0 M  4600  SHELTER  DEPLOYMENT) 


Figure  10.  Proposed  network  hierarchy. 


The  level  1  program  summary  is  a  highly  aggregated  network  which  selects 
only  major  elements  of  the  construction  program.  Support  activities  not 
directly  related  to  the  program  would  probably  not  be  included;  however,  they 
would  influence  the  status  of  level  1,  because  they  would  be  integrated  at  the 
level  2  member-level  networks.  This  summary  would  be  combined  with  equivalent 
information  reflecting  the  status  of  the  weapons  system  development  to  provide 
coordinated  high-level  briefings. 

Since  the  data  is  so  highly  summarized  in  level  1,  it  is  apparent  that 
some  interfaces  with  Air  Force  organizations,  such  as  SATAF,  must  occur  at  a 
lower  level  in  the  system.  A  reasonable  interface  appears  to  be  at  the  member 
network  level.  This  level  is  high  enough  that  CEMXPA  would  retain  some  con¬ 
trol  over  the  dissemination  of  information  (e.g.,  release  missile  shelters  to 
SATF) ,  but  provide  the  necessary  coordination  in  the  field. 

The  member  networks  in  summary  level  2  are  separated  into  the  major  ele¬ 
ments  of  the  program  and  other  supporting  activities.  Contract  networks  are 
connected  to  a  member  network  that  they  support;  this  indicates  that  summar¬ 
ized  data  will  be  available  for  automatic  progress  updates.  Sometimes,  member 
networks  indicate  that  responsibility  is  split  between  a  design  District  and 
CEMXCO.  This  approach  is  feasible  if  the  work  is  cleanly  turned  over  from 
design  to  construction.  It  is  more  likely,  however,  that  when  CEMXCO  is 
staffed,  the  member  network  will  need  to  be  split.  This  would  eliminate  any 
problems  with  transferring  the  network  from  one  office  to  another. 

The  third-level  networks  provide  the  detail  needed  to  automatically  sup¬ 
port  progress  reporting  to  their  respective  summarized  level  2  network.  In 
moot  cases,  this  data  is  reported  from  contractor  networks  but  in  some  cases 
(e.g.,  real  estate),  additional  detail  was  also  necessary  in  noncontract  net¬ 
works.  This  was  done  to  prevent  level  2  networks  from  becoming  unnecessarily 
detailed  and  awkward  to  use. 


6  RECOMMENDATIONS 


Based  on  the  evaluation  of  alternative  networking  schemes,  it  is  recom¬ 
mended  that  the  basic  hierarchical  networking  system  with  an  activity  coding 
summarization  scheme  be  developed  to  support  the  MX  construction  program.  In 
addition,  the  developers  of  Project/2  should  be  contracted  to  evaluate  the 
feasibility  of  interfacing  Project/2  with  an  external  data  base  management 
system. 
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